LGTM

A few things:

1. This has conflicts due to Restructure how devices are created and automatically cleaned up. #1035 and needs to be updated
2. Wouldn't we also need a change in api-query.cpp to not abort after calling initializeDevices? This might be something that changed since Restructure how devices are created and automatically cleaned up. #1035
3. The commit message here could be significantly simplified, which would help make it clear what this does. Commit messages shouldn't repeat every change that a commit will make, but instead focus on pointing out why the change is being made. Here, it would suffice to point out the problem (we quit after each device) and the high level of how we're fixing it (collect the errors, report them, and continue on).

3. The commit message here could be significantly simplified, which would help make it clear what this does. Commit messages shouldn't repeat every change that a commit will make, but instead focus on pointing out why the change is being made. Here, it would suffice to point out the problem (we quit after each device) and the high level of how we're fixing it (collect the errors, report them, and continue on).

@bogner just to make sure we're talking about the same commit message:

Device::initialize() returns early when any backend fails to initialize, preventing subsequent backends from being discovered. For example, a Vulkan initialization failure (e.g. VK_ERROR_INCOMPATIBLE_DRIVER when MoltenVK is not installed) blocks Metal device discovery on macOS.

Collect backend initialization errors with joinErrors() and return them together instead. Also make lit.cfg.py resilient to an empty device list from api-query.

This explains why something is wrong together with an example case of when that has an effect (Vulkan init on MacOS), followed by how it was fixed (using joinError(), and the drive-by note aboutlit.cfg.py not allowing empty yaml lists initially).

Is that still too much?